AWS再入門ブログリレー Amazon AppStream 2.0 編
しばたです。
当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2020』の 2日目のエントリです。
このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。
AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2020 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。
では、さっそくいってみましょう。2日目のテーマは『Amazon AppStream 2.0』です。
Amazon AppStream 2.0 とは？
Amazon AppStream 2.0はその説明に
Amazon AppStream 2.0 は、完全マネージド型のアプリケーションストリーミングサービスです。
とある様にフルマネージドなアプリケーションストリーミングサービスです。
アプリケーションストリーミングが何かというと「アプリケーションの実体はリモート環境のサーバーで動作しているが、画面の描画をストリーミング転送してあたかもローカルでアプリケーションが動作している様に見せるアレ」です。
Windows Serverに標準搭載されているMicrosoft RemoteAppやCitrix社のCitrix Virtual Apps(旧称XenApp)などと同様のやつと言うほうがこれらの製品を知っている方にはわかりやすいかもしれません。
完全マネージド型とある様にその基盤はAWSによって管理されユーザーはアプリケーションの利用に注力することができます。
Amazon WorkSpacesとの違い
AWS内の類似のサービスにAmazon WorkSpacesがありますが、Amazon WorkSpacesは「仮想デスクトップ」という形でユーザーに仮想マシン全体を公開するのに対し、AppStream 2.0は「アプリケーションストリーミング」という形で特定のアプリケーションのみを公開する違いがあります。
より詳細な両者の差異とそれぞれのユースケースについては以下の記事をご覧いただくとよいでしょう。
Why 2.0?
Amazon AppStream 2.0 という以上は当然AppStream 1.0もあったはずなのですが、今となっては過去のAppStreamに関する情報はほとんどありません。
AppStream自体は2013年のre:Inventで発表され2014年に「Amazon AppStream」として公開されています。
公開当初からアプリケーションストリーミングサービスという根本は変わっていないのですが、今の様にサーバーサイドのインフラとクライアントアプリケーションをフルセットで提供するものではなく、クライアント側がSDKベースでユーザー自作のアプリケーションに組み込んで使う形態のサービスだった様です。
ユースケースとしても所謂クラウドゲーミングを想定しており今の様な汎用アプリケーション向けではなかった様です。
(こちらについては私がクラスメソッドに入社するはるか昔のはなしなので断言できない点はご了承ください)
- 「re:Invent 2013」で発表されたAmazon Web Servicesの新サービスを振り返る (新たなゲームを作るAmazon AppStream)
- [AWS re:invent 2013 Report] Amazon AppStream
- 【速報】Amazon AppStreamがデスクトップアプリケーション配信サービスになって帰ってきた #reinvent
Amazon AppStream 2.0入門
はじめに
ここからAppStream 2.0の入門に入りますが、最初に言い訳をさせてください。
この記事を書くと決めてからAppStream 2.0についていろいろ情報を集めたのですが、以下のBlack Beltの資料が非常に良くまとまっており、正直私が記事を書く必要が一切無いくらいよくまとまっています。
(この資料を見つけてしまい「もう全部これで良いじゃん」となった私の気持ちを察していただけるとありがたいです...)
なのでまずはこの資料を一読していただくのが一番良いと思います。
以降はこの資料からポイントとなる部分についてかいつまんで解説していきます。
基本的な概念
AppStream 2.0には独特の概念があるので最初に触れておきます。
まずは以下の図をご覧ください。
(20191126 AWS Black Belt Online Seminar Amazon AppStream 2.0 P36より引用)
この図にある以下の用語を押さえておく必要があります。
1. イメージ (Image)
公開するアプリケーションを持つ仮想マシンのイメージです。
AppStream 2.0専用のAMIと考えておけばよいでしょう。
公開するアプリケーションは千差万別のためAWSでは基本ベースとなるイメージのみを提供しており、ユーザーが公開するアプリケーション設定を施した独自のイメージを作って利用するのが基本となります。
(一応AWSによるサンプルイメージも提供されています)
イメージのOSは2020年8月現在では
- Windows Server 2012 R2
- Windows Server 2016
- Windows Server 2019
の3OS提供されています。
2. イメージビルダー
ベースとなるイメージからユーザー独自のイメージを作るためのツールです。
ベースとなるイメージ内部にはImage Assistantという設定ツールが用意されており、このツールで公開するアプリケーションの設定などを施すことができます。
3. フリート (Fleet)
公開するイメージの配備情報（インスタンスタイプ、展開VPCなど）やスケールアウト・スケールインのためのポリシーをまとめたものになります。
フリートを起動すると実体となるインスタンスが起動され配備されることになります。
Fleetの意味は「艦隊」や「車隊」ですのでそこから連想するとわかりやすいかもしれません。
4. スタック (stack)
AppStream 2.0では公開するアプリケーションをスタックという単位で管理します。
実体としてはフリートと利用ユーザー環境まわりの設定などを合わせたものになります。
ちなみにスタックごとにその外観をカスタマイズできたりもします。
構成図
AppStream 2.0のネットワーク的な構成は以下の様になっています。
(20191126 AWS Black Belt Online Seminar Amazon AppStream 2.0 P43より引用)
ユーザーはインターネット経由でAppStream 2.0のアプリケーションを利用できますが、WorkSpacesと同様にAWSが管理するマネージドVPC内にストリーミングゲートウェイと呼ばれるエンドポイントを持ちそこからフリートにアクセスする形になります。
フリートの実体はマネージドVPCにあるもののユーザー管理のVPCにENIを生やすことであたかもユーザーVPC内にフリートがある様に見せかけます。この点もWorkSpacesと同様ですね。
ただ、AppStream 2.0では2019年8月からVPC Endpointがサポートされ、VPC Endpoint経由でストリーミングゲートウェイにアクセスすることが可能になっており、下図の様にインターネットを介さずに公開アプリケーションをストリーミングすることが可能になっています。
(認証等の通信はインターネットアクセスを要するので注意)
(20191126 AWS Black Belt Online Seminar Amazon AppStream 2.0 P44より引用)
対応クライアント
AppStream 2.0はWindows向けの専用クライアントとHTML 5をサポートするブラウザから利用することができます。
ブラウザ利用の際に特定のプラグインなどは必要とせず、iPadやAndroidタブレットのブラウザからも利用することが可能です。
料金
AppStream 2.0の利用料金は要素ごとに分かれています。
詳細は公式の案内を確認していただきたいですが、ざっくり以下の要素に対して課金されます。
- フリートの利用料金 : フリートを起動している時間に応じた課金
- フリートを「常時稼働」させるか「オンデマンドで稼働させるか」で料金が変わります
- イメージビルダーの利用料金 : イメージビルダーを起動している時間に応じた課金
- ユーザー料金 : ユーザー一人あたり毎月一定の利用費がかかります。
- これはWindows Server OSでリモートアプリケーションを公開する以上利用者ごとにRemote Desktop SAL(※SPLA契約下なのでRemote Desktop CALでなくSAL)が必要になり、そのライセンス費用が請求されます。
やってみた
あとは実際に試してみるほうがイメージがつかみやすいかと思いますので簡単な環境を作ってみます。
1. ユーザー
最初にAppStream 2.0を利用するユーザー情報を登録しておきます。
マネジメントコンソールからAppStream 2.0を選択し、左欄の「User Pool」を選びます。
ユーザーが一人もいない場合は下図の様な画面になりますので「Create User」をクリックします。
ユーザー登録画面が表示されるので適宜作成します。
作成した結果はこんな感じ。
ユーザーを作成した後は登録したメールアドレス宛に一時パスワードが通知されます。
このユーザーはスタックを作った後で利用します。
ちなみに余談ですが一度作ったユーザーはCLIからしか削除できませんので注意してください。
2. イメージ
次にイメージを作成します。
左欄の「Images」を選ぶとイメージ一覧が表示されますが、現時点ではAWS提供のベースイメージしか無いのでImage Builderを使い自分用のイメージを作ってやります。
「Image Builder」のタブを選択して「Launch Image Builder」をクリック。
カスタムのベースとなるイメージを選択してやります。
今回はGeneral PurposeのWindows Server 2019のイメージを選択しました。
イメージビルダー名やImage Builderで起動するインスタンスタイプなどを指定します。
続けてImage Builderで起動するインスタンスの配置先VPCを指定します。
実際の運用においては予め利用VPCを構築しておく必要がありますが、今回はお試しなのでデフォルトVPCを利用します。
※ちなみに「Default Internet Access」欄にチェックを入れてサブネットをPublicサブネットにしておくとAWS側でよしなにインスタンスにPublic IPを割り当てインターネットアクセスできる様にしてくれます。
最後に確認画面が表示されますので間違いがないことを確認して「Launch」をクリック。
するとImage Builderで管理するベースイメージが構築されますのでステータスが「Pending」→「Runnig」になるまでしばらく待ちます。
ステータスが「Runnig」になるとイメージに接続することができる様になるので「Connect」をクリック。
するとWEBクライアントからイメージに接続されユーザー選択ダイアログが表示されるので「Administrator」を選択。
これでAdministratorでデスクトップアクセスできるので、OS設定のカスタマイズや追加アプリケーションを適宜インストールします。
カスタマイズが終わったらデスクトップにある「Image Assitant」をクリック。
すると公開アプリケーション設定のためのウィザードが開始されますので順に進めていきます。
はじめに公開するアプリケーションを登録します。
「+ Add App」欄をクリックするとアプリケーションを増やせます。
(細かい手順は割愛しますが今回はデフォルトでインストールされているFirefoxと追加インストールしたPowerShell 7を対象にしました)
次に管理者以外のユーザー(Template User)でログインしなおしユーザー毎で必要な設定をします。
ユーザー毎の設定が完了したら「Image Assitant」を起動し、Administratorユーザーに切り替えます。
(Template UserでImage Assitantを起動した場合はこんな感じ)
Administratorユーザーに戻ると「Save settings」ボタンがクリック可能になっているのでクリックしてユーザー毎の設定を保存します。
設定の保存が完了すると次のフェーズに進み動作確認を促されます。
Test Userに切り替えて動作確認をしてください。
動作確認して問題なければ次のフェーズに進みます。
「Launch」ボタンをクリックしてアプリケーション起動の最適化を実施します。
次のフェーズに進みますので、ここでカスタマイズしたイメージ情報の設定を行います。
最後に「Disconnect and Create Image」ボタンをクリックすれば完了です。
これでベースイメージを元にカスタムイメージの作成が開始されます。
カスタムイメージの作成にはそれなりに時間がかかるので完了するまで待ちます。
作成したイメージのステータスが「Available」になっていればOKです。
3. フリート
続けてフリートを作ります。
左欄の「Fleets」を選びます。フリートがひとつもない場合は下図の様な画面になりますので「Create Fleet」をクリックします。
フリートの基本情報を登録して、
前項で作成したイメージを選択、
フリートのインスタンスタイプや起動方式などを選択、
(今回はここの詳細は割愛します。すべてデフォルト設定で進めていきます)
フリートの配置先VPCを指定。
Image Builder同様実際の運用においては予め利用VPCを構築しておく必要がありますが、今回はお試しなのでデフォルトVPCを利用します。
最後の確認をして「Create」ボタンをクリックでフリートを作成します。
フリートの作成にもそれなりに時間がかかります。
ステータスが「Starting」→「Running」になれば完了です。
4. スタック
最後にスタックを作ります。
左欄の「Stacks」を選びます。スタックがひとつもない場合は下図の様な画面になりますので「Create Stack」をクリックします。
スタックの各種設定を入力します。
(今回は最低限必要な情報のみ設定しています)
ユーザー向けに永続ストレージを提供するか選択。
デフォルトではS3を永続ストレージの保存先にしますが、Google Drive for G SuiteやOneDrive for Businessといったオンラインストレージも使うことが可能です。
クライアントからのクリップボード、ファイル転送、プリンターリダイレクトの可否やアプリケーション設定を永続化するかを選択。
設定内容を確認して「Create」ボタンをクリックでスタックを作成します。
スタックはただちに出来上がります。
5. ユーザーとスタックの紐づけ
作成したスタックをユーザーが利用するために紐づけを行います。
ユーザープールから作成したユーザーを選択し「Actions → Assign stack」を選びます。
ダイアログが表示されるのでStack欄に紐づけるスタックを選択します。
するとユーザーのメールアドレスにログイン案内のメールが届きます。
6. WEBクライアントからのアクセス
これでようやく準備ができましたので、ブラウザからログイン案内のURLにアクセスします。
するとAppStream 2.0のログイン画面になりますので、ユーザー登録時のメールにある「メールアドレス」と「一時パスワード」を入力します。
パスワードの変更を求められますので、任意のパスワードに変更してください。
するとログインでき、さきほど登録したアプリケーションがリストアップされます。
アプリケーションのアイコンをクリックすると下図の様な感じでアプリケーションがブラウザ内で起動します。
補足. Windowsクライアントの場合
補足としてWindowsクライアントを起動した場合は以下の様な画面が表示されます。
(クライアントのインストール手順は割愛)
画面中央のテキストボックスにログイン案内のURLを入力し「Connect」ボタンをクリックするとログイン画面に遷移しますのであとはWEBクライアントと同様です。
Windowsクライアントには「native application mode」というものがあり、このモードにすると下図の様に公開アプリケーションを独立したアプリの様に表示することができます。
native application mode以外にも以下の要求がある場合はWindowsクライアントを使うと良いでしょう。
-
2 台以上のモニターまたは 4K 解像度のサポートが必要なユーザー。
-
AppStream 2.0 を介してストリーミングされたアプリケーションで USB デバイスを使用しているユーザー。
-
ストリーミングセッション中にキーボードショートカットを使用しているユーザー。
-
ストリーミングセッション中にローカルドライブとフォルダへのシームレスなアクセスが必要なユーザー。
-
ローカルにインストールされたアプリケーションを操作するのとほぼ同じ方法で、リモートストリーミングアプリケーションを操作することを希望するユーザー。
最後に
以上、『AWS 再入門ブログリレー 2020』2日目のエントリ『Amazon AppStream 2.0』編でした。
明日 (8/5) は崔陽一による「AWS Direct Connect」の予定です。お楽しみに！!
